Ray Tracing Triangular Meshes

This paper describes two approaches that allow us to intersect rays with triangular meshes more quickly by amortizing computation over neighbouring triangles. The first approach accomplishes this by performing the in-out test for each triangle using three plane equations, each one representing a boundary edge for the triangle. Each plane is shared between four neighbouring triangles and the cost of intersecting each plane is amortized over all four of these triangles. The second approach, which is more numerically robust than traditional approaches, uses Plücker coordinates to decide on which side of a triangle’s edge a ray passes through. In this case side information can be amortized over two triangles. Speedups of over 25% have been recorded when incorporating these approaches in a typical ray tracer. Extending the algorithms to more general polygonal meshes is straightforward. The Problem When rendering higher-order surfaces, such as parametric patches, many ray tracers tessellate these surfaces into polygonal meshes and then intersect the resulting polygons (typically triangles) directly [1, 2]. The hope is that the simplicity and speed of the ray-triangle intersection computation will more than offset the fact that many more objects will now hav e to be intersected. To get the most performance out of this approach the cost of ray-triangle intersection has to be minimized. Previous solutions have taken approaches that concentrated on dealing with triangles independently. In this paper we develop two algorithms that try to capitalize on the fact that these triangles are part of a mesh and thus try to reduce the total cost of intersecting these triangles. Previous Solutions Most graphics systems associate transformations with individual objects in a scene, allowing the user to independently modify each of these objects. When intersecting an isolated arbitrary triangle, the best solution is to precompute a transformation that takes the arbitrary triangle and transforms it to the x-y plane with the vertices mapped to (0, 0, 0), (0, 1, 0), (1, 0, 0). (This transformation is concatenated to the object’s transformation and thus requires no extra space or computation.) In this coordinate system computing the ray-triangle intersection is simplified [3]. First, the intersection of the ray and the x-y plane plane is performed (this is simpler than intersecting an arbitrary plane, requiring about 8 flops) and then the intersection point (in 2-D) can be tested to see if it lies within the requisite triangle (only 4 flops). For each triangle the transformation and its inverse must be stored (21 floating-point numbers total) and every ray must be transformed independently for each triangle (36 flops) even before the actual intersection computation can begin. This solution, which requires 48 flops and is optimal for isolated triangles, needs too much space for polygonal meshes. The approach most renderers use when intersecting triangular meshes [2] is to precompute and store a plane that the triangle is embedded in with each triangle and to share the vertex information amongst neighbouring triangles. The ray intersects the triangle’s plane (a general plane now) and if the t value of the ray’s intersection is reasonable, the actual intersection point is computed: pt = origin + t ⋅ → dir (21 flops). This intersection point is then tested to see if it is truly inside the triangle; this is typically done using a barycentric approach (approximately 25 flops). The total cost is thus about 46 flops worst case [1, 4]. More recent work by Spackman [5] and Green and Worley [6], by concentrating on determining when the actual intersection point is inside the triangle, have improved on this. Spackman noted that part of the barycentric computation can be precomputed (extra storage is now required per triangle); this reduces the number of flops to determine if there is an intersection to 31 flops worst case. Greene and Worley project the triangle into 2D and store the 2D plane equation for each triangle’s edge with the triangle. The intersection point is inserted into these plane equations and reject it if it is on the wrong side. This approach requires 33 flops worst case and also needs extra storage. Because the above approaches to triangle intersection treat triangles independently there is no way to capitalize on neighbourhood information to reduce the total computational cost. In the next two sections we introduce two such approaches. Approach A: Boundary Planes Consider figure 1a. It shows a triangle embedded in the plane and rather than using vertices, we use three boundary planes to define the extent of the triangle. We can now use these planes to decide if a point is inside. In our example, the normals point out. Thus p0 would be inside the triangle (it is on the inside of all the boundary planes) and p1 would be outside (p1 is on the outside of at least one plane). Using these boundary planes to decide if a point is inside when intersecting triangles (21 flops) is a little faster than the barycentric approach but it requires more space for the planes.